Wolf-3D Generic engine
			----------------------


    HELP! I have been working on the generic wolf-3D style engine and am
having difficulty getting some problems ironed out. If anyone would be
willing to look over the source and see if they can determine where the
errors are I would greatly appreciate it.

    Run XTEST.EXE to see the current results of the engine (XTEST.C)

    Currently there are two routines to draw the view on the screen. The
    latest one is invoked by default. To use the older version type

			 XTEST -O

    on the command line. Both routines suffer from the same
    problems however....

    Keyboard control is all I have in there so far and I borrowed the
routines in a hurry from Michael Mstowski's SCPY program. They work good
and my thanks to Michael if he's listening.

    XTEST also temporarily uses the VGA240 library that was found in the
Game Design forum to draw the horizontal and vertical lines in mode X.

==============================================================================
Keyboard control:

    Esc	    - Exits program
    Right   - Turns right 4 degrees
Ctrl Right  - Turns right 45 degrees
    Left    - Turns left 4 degrees
Ctrl Left   - Turns left 45 degrees
    Up	    - Moves forward 2 units
    Home    - Moves forward 128 units
    PgUp    - Moves forward 20 units
    End	    - Moves backwards 128 units
    PgDn    - Moves backwards 20 units


==============================================================================
Files and what they are for:

xtest.c	    - Code I am trying to get working
xtest.exe   - Compiled and ready to run
f.dat	    - Table of angle offsets used during the scanning process

==============================================================================
Current problems with xtest code:

1. Spikes or divits in the walls at certain distances and angles. This is the
   main one I've been trying to concentrate on but so far no luck. My thought
   is that there is a round-off error when using the cosine table to adjust
   the actual distance from the wall to the current X,Y position.


			 D2
		      P-------W <--- Hit on a wall
		      |	    / <----- Angle currently scanning for a wall
		      | D1/
		      | /
		      @ -----------> Current view angle
		      |
		      |
		      | <----------- Perpendicular angle to view angle
		      |

		  Figure 1

    From the figure lets say the current angle we are facing is to the right
(or angle 0). The scanning routine starts 45 degrees to the left of the current
angle for the first pixel column of the display. We cast a ray out (either x
or y) and finds a wall (W). Distance D1 can be calculated from the square root
of the deltaX squared and deltaY squared values. But D1 will always be from the
specific point where we are standing. What seems to be needed is an adjusted
distance that is always perpendicular to the current angle we are facing. So
by taking the cosine of the scanning angle and multiplying that by D1 we get
the adjusted distance D2. (Hopefully this is the right way to go....) This will
give us the distance from the wall to point P which should remain fairly
constant for flat walls when we face them directly.

It is here where the spikes/divits appear. If the distance adjustment is not
made then the flat walls we are facing appear curved as we move further away
from the angle we are facing (the fishbowl or fisheye effect mention in previous
threads). But the spikes disappear!




2. The other immediate problem is that some corners of walls are missed during
   the scanning process as if the current angle being scanned doesn't strike
   the correct wall in either the X or Y direction. Debugging has shown this
   to be the case where the X coordinate is right on a 64 boundary but the
   Y coordinate just misses the wall (this is during an X scan). I haven't
   looked into this one as much yet, but I suspect it is again related to
   a round-off error when using the tangent table.



If anyone can see what's wrong here or can offer any suggestions it would be
greatly appreciated. Once I get past these hurdles my goal is to create a
generic library function that can be included in any program. I am also
planning on uploading the completed engine source code for public use since
it is such a popular engine and I think we could all see some fantastic
games/applications built around it.....

I would be willing to collaborate with anyone who is interested in pursuing
this "adventure" to a logical conclusion. I can code but I can't draw so any
graphic artist who want to join in please let me know.....

Thanks in advance

Lary Myers
76004,1574